nnml server just
for nnmairix, but then you have to explicitly set the
corresponding server variable nnml-get-new-mail to
nil. Otherwise, new mail might get put into this
secondary server (and would never show up again). Here's an
example server definition:
(nnml "mairix" (nnml-directory "mairix") (nnml-get-new-mail nil))
(The nnmaildir back end also has a server
variabe get-new-mail, but its default value is
nil, so you don't have to explicitly set it if
you use a nnmaildir server just for mairix.)
nnmairix groups (put them in
gnus-registry-unfollowed-groups). Be extra
careful if you use
gnus-registry-split-fancy-with-parent; mails which
are split into nnmairix groups are usually gone
for good as soon as you check the group for new mail (yes, it
has happened to me...).nnmairix groups (you shouldn't be able to,
anyway).nnmairix groups (though I have no idea
what happens if you do).nnmairix uses a rather brute force method to
force Gnus to completely reread the group on the mail back end
after mairix was called—it simply deletes and re-creates
the group on the mail back end. So far, this has worked for me
without any problems, and I don't see how nnmairix
could delete other mail groups than its own, but anyway: you
really should have a backup of your mail folders.nnmairix group, it is gone for good.nnmairix groups, the
“zz_mairix-*” groups will accumulate on the mail
back end server. To delete old groups which are no longer
needed, call nnmairix-purge-old-groups. Note that
this assumes that you don't save any “real” mail in
folders of the form
zz_mairix-<NAME>-<NUMBER>. You can
change the prefix of nnmairix groups by changing
the variable nnmairix-group-prefix.A problem can occur when using nnmairix with
maildir folders and comes with the fact that maildir stores
mail flags like ‘Seen’ or ‘Replied’ by appending chars
‘S’ and
‘R’ to the
message file name, respectively. This implies that currently
you would have to update the mairix database not only when
new mail arrives, but also when mail flags are changing. The
same applies to new mails which are indexed while they are
still in the ‘new’ folder but then get moved to
‘cur’ when
Gnus has seen the mail. If you don't update the database
after this has happened, a mairix query can lead to symlinks
pointing to non-existing files. In Gnus, these messages will
usually appear with “(none)” entries in the
header and can't be accessed. If this happens to you, using
G b u and updating the group will usually fix
this.